The present invention relates generally to a system providing methods for facilitating development of software programs, with particular emphasis on decreasing the time such a system spends on recompiling source modules during program development.
Before a digital computer may accomplish a desired task, it must receive an appropriate set of instructions. Executed by the computer's microprocessor, these instructions, collectively referred to as a "computer program," direct the operation of the computer. Expectedly, the computer must understand the instructions which it receives before it may undertake the specified activity.
Owing to their digital nature, computers essentially only understand "machine code," that is, the low-level, minute instructions for performing specific tasks--the sequence of ones and zeros that are interpreted as specific instructions by the computer's microprocessor. Since machine language or machine code is the only language computers actually understand, all other programming languages represent ways of structuring "human" language so that humans can get computers to perform specific tasks.
While it is possible for humans to compose meaningful programs in machine code, practically all software development today employs one or more of the available programming languages. The most widely-used programming languages are the "high-level" languages, such as C or Pascal, or more recently Java. These languages allow data structures and algorithms to be expressed in a style of writing which is easily read and understood by fellow programmers.
A program called a "compiler" translates these instructions into the requisite machine language. In the context of this translation, the program written in the high-level language is called the "source code" or source program. The ultimate output of the compiler is a compiled module such as a compiled C "object module," which includes instructions for execution ultimately by a target processor, or a compiled Java class, which includes opcode instructions for execution ultimately by a Java virtual machine. Although a compiled module includes code for instructing the operation of a computer, such a module itself is typically not in a form which may be directly executed by a computer. In other words, it does not form the final program which is executable on a computer. Instead, it must undergo a "linking" operation before the final executable program is created.
Linking may be thought of as the general process of combining or linking together one or more compiled object modules to create an executable program. This task usually falls to a program called a "linker." In typical operation, a linker receives, either from the user or from an integrated compiler, a list of object modules desired to be included in the link operation. The linker scans the object modules from the object and library files specified. After resolving interconnecting references as needed, the linker constructs an executable image by organizing the object code from the modules of the program in a format understood by the operating system program loader. The end result of linking is executable code (such as an .exe file) which, after testing and quality assurance, is passed to the user with appropriate installation and usage instructions.
Conventionally, creation of a software program includes creation of individual source code modules. This approach allows the developer to simplify program development by dividing functionality available in the program into separate source modules. When multiple source modules are employed for creating a program, interdependencies between the individual modules often exist. Program logic in one module can, for instance, reference variables (i.e., symbols) imported from another module. By the very same token, that module can also export its own symbols, making them available for use by other modules.
Because of potential interdependencies between modules, an issue arises when a particular source module is modified (e.g., edited by a user). In particular, regardless of which language or development tool is employed, a problem exists as to how one recompiles source modules which might have changed (e.g., as a result of a programmer editing a particular source module). When building C/C++ applications, for instance, the current technique is to employ a "make" tool for instructing the compiler to recompile every source that depends on a modified and recompiled source, regardless of the type of dependency between both sources. This is a suboptimal approach, however. Consider, for instance, the act of modifying a comment in source code--that is, a modification which does not impact the final compiled program. Using existing approaches, the act of modifying a comment in a source results in a recompilation of any dependent source modules (i.e., the clients of the source). In turn, the clients of the latter source will also be recompiled. Specifically, the system must ensure that such a change is compatible with the other modules of the program. A particular concern is, therefore, that a given change might "break" the program, because the change is incompatible with other, dependent modules.
The present day approach to the problem is unsophisticated. When faced with a modification to a given source module, development systems today simply recompile all dependent modules, for ensuring that the dependent modules remain compatible with the new modification. Such an approach is suboptimal, however. Consider, for instance, a simple modification to a source module, such as the abovementioned editing a single source code comment. Since source code comments do not lead to the generation of program code or provide any symbol information, such a change will have no impact on modules which are otherwise dependent on the just-changed module. Nonetheless, the current approach is to still simply recompile all dependent modules. Such an approach is clearly suboptimal as none of the dependent modules in the example actually require compilation.
The problem is more general in nature, however. For a given change to a source module, the need to actually recompile dependent modules may include none, some, or all of the dependent modules. Stated generally, therefore, the system needs to discern at some level the nature of the modification to the given source module so that it can proceed to only recompile those modules (if any) affected by the change. By reducing the number of recompiles, the system can speed up the edit/compile cycle which serves as the cornerstone of modern day software development.
What is needed is a system with methods for recompiling only those source modules which really need to be recompiled after a modification. Minimizing the number of recompilations can greatly speed up the process of software development. The present invention fulfills this and other needs.